Multi-commerce channel wallet for authenticated transactions

ABSTRACT

A phone-based electronic wallet providing authenticated transactions across multiple channels of commerce. The electronic wallet may be used for point-of-sale payments, remote mobile payments and/or web-based payments, and may use authentication tools such as offline PINs, SecureCode PINs and/or online PINs.

This application claims the benefit of U.S. Provisional Application Ser.No. 61/372,955 filed Aug. 12, 2010 and U.S. Provisional Application Ser.No. 61/468,847 filed Mar. 29, 2011, the disclosures of which are herebyincorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

The present invention relates to transactions for payment ofgoods/services and, more particularly, to a phone-based electronicwallet providing authenticated transactions across multiple channels ofcommerce.

Both credit cards and debit cards are commonly used in the retailenvironment for the purchase of goods and/or services. Such cards arepopular with consumers, and merchants accept these cards as a necessarypart of doing business, i.e., they provide an effective substitute tocash and checks.

These card-based transactions are typically performed across multiplechannels of commerce. For example, card-based transactions may beperformed in person at a retail outlet, via a computer connected to theinternet, via a mobile phone and/or via a company-based call center(e.g., a 1-800 number for a catalog company). These various transactionsare conducted in different ways and, accordingly, have different levelsof fraud risk associated therewith. In addition, the mentionedtransactions generally require that the consumer have his or her card inhand to either present to the cashier in a retail environment, or toenter the requested information via the internet and/or over thetelephone. Those knowledgeable in the field will recognize that the riskof financial fraud is greater during remote transactions because thereis less ability for the merchant to verify the identity and authenticityof the cardholder.

It will also be appreciated that in today's environment it is common fora consumer to carry his or her cell/mobile phone on their person at alltimes. In fact, on many occasions it is more likely that the consumerwill be carrying his/her phone, than carrying his/her wallet. Companieshave attempted to tap into this trend by offering/facilitating variousphone-based applications directed to a whole range of services. Therecent growth of so-called “smart phones” has greatly increased theinterest of companies in this area. As a result, more and moretransactions are likely to be performed from a remote location, e.g.,ordering a product over the internet while standing in line. However, asthe number of remote transactions increase, so does the risk offinancial fraud.

There is therefore a need in the art for a method and system forauthenticating electronic transactions across multiple channels ofcommerce. There is a further need in the art for a method and systemwhich operates in conjunction with a phone (e.g., a smart phone) forauthenticating financial transactions whether initiated in person, overthe internet via a stand alone terminal, via the placement of a call tothe call center of a company, and/or via a transaction initiated withthe very same phone. Finally, there is a need in the art for a methodand system which allows a bank or other financial institution to reducefees to merchants conducting remote electronic transactions whenutilizing enhanced authentication techniques, and to limit/reverse theshifting of fraud liability to the merchant for such remotetransactions.

SUMMARY OF THE INVENTION

The present invention provides a mobile-phone centric electronic walletproviding the security of a virtual card terminal for online andoff-line purchases. A wallet server (e.g., an application running in acloud) and synchronized companion mobile and computer interface enablesconsumers to make purchases (which can include: retail, e-commerce,mobile, call center, etc) and use the mobile phone to authenticateagainst one of the authentication techniques tied to the chosen card(which can include: an offline PIN utilizing a secure memory chip, aMasterCard SecureCode PIN, and/or an online PIN such as an ATM PIN)where the necessary transaction and card specific authentication andprocessing method is directed by a central directory. The authenticationprocess of the present invention allows participating banks to deem suchtransactions as more fully authenticated, which will allow them to lowerthe costs charged to merchants. The authentication process of thepresent invention will also limit/reverse the shifting of liability tothe merchant since these more fully authenticated transactions will haveless fraud associated therewith.

This system with its various authentication mechanisms will preferablyutilize a central, hosted directory, which, when queried by the walletapplication during a transaction, will instruct the wallet how thetransaction needs to be authenticated and processed, depending on thecard used and type of transaction. In all instances, the authenticationresult and authentication method will be communicated from the wallet tothe merchant via specific transaction codes and/or transaction tokensthat will further enable proper risk scoring, authorization processing,and enforcement of specific scheme rules and terms and conditions (e.g.pricing, rules, liability shift, etc.) by the merchant acquirer. Thewallet facilitates authentication from multi-commerce channels and willleverage multi-band communication to facilitate transactionauthentication.

For retail (Point-of-sale (POS)/Face-to-Face (F2F)) purchasetransactions, the consumer may use the PayPass contactless capabilitieswhich may be a feature of a chip located in the phone. For highertransaction value amounts where a PIN may be required, the wallet willprompt the user for the PIN on the phone. Successful authentication willbe communicated from the wallet to the merchants or its Acquirerdirectly for approval processing.

For some remote (e-commerce, mobile or call center) purchasetransactions, the consumer will employ his/her mobile phone and thewallet capabilities as a virtual POS terminal. In this case, when theconsumer makes a purchase (e.g., through a computer or the mobile phoneitself), the wallet will prompt the user for the PIN on the phone andenable a secure verification of the PIN value entered by the user,either in a pure offline mode, against the algorithm associated with thesecure element on the phone, using for example the EMV protocol, or inan online mode, by encrypting the PIN and transmitting it. Successfulauthentication will be communicated from the wallet to the merchant'scheckout system to be relayed to the Acquirer for approval processing.

For other remote (e-commerce, mobile or call center) purchasetransactions, this invention builds on the pre-existing MasterCardSecureCode (MSC) system. It is contemplated herein that the SecureCodeprotocol can be extended to include a novel SecureCode walletApplication Programming Interface (API), to enable a MSC validationwithin the wallet interface through the wallet API, instead of throughan internet browser session/window to communicate with the bank'sauthentication server. To facilitate this, the mobile phone will promptthe user for entry of the MSC password or PIN within the wallet-driveninterface on the phone and communicate securely with the ACS (the bank'sMSC authentication server). Successful authentication will becommunicated from the wallet to the merchant's checkout system to berelayed to the Acquirer for approval. This last step preferably replacesthe pre-existing MSC Merchant software, thus reducing the implementationrequirements for the merchant. Finally, this interface will preferablyallow setup and reset of a MSC password or PIN, again without the needto use a separate browser window or session with the bank'sauthentication server.

Thus, the system and method of the present invention provide anelectronic wallet for authenticating transactions across multiplechannels of commerce using the consumer's own mobile phone. The presentinvention provides better economics for merchants through lower feestructures, and limits/reduces the shifting of fraud liability to themerchant for remote transactions. The present invention is scalable indesign to provide easy integration for merchants, and to avoid issuer byissuer sales and implementations. It is also easy to deploy directly tocustomers. Finally, the present invention will promote profitability bydriving transaction volumes and revenues.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematical representation of a mobile phone-basedpayment/authentication system;

FIG. 2 is a flow chart depicting the wallet application of the presentinvention being used in an e-commerce transaction originating via acomputer, the wallet application cooperating with a secure element onthe phone and an offline PIN;

FIG. 3 is a flow chart depicting the wallet application of the presentinvention being used in an e-commerce transaction originating viacomputer, the wallet application cooperating with a SecureCode PIN forauthentication;

FIG. 4 is a flow chart depicting the wallet application of the presentinvention being used in an e-commerce transaction originating via aphone, the wallet application utilizing an online PIN forauthentication;

FIG. 5 is a flow chart depicting the wallet application of the presentinvention being used in an e-commerce transaction originating via aphone, the wallet application not being associated with an offline PIN,a SecureCode PIN and/or online PIN;

FIG. 6 is a flow chart depicting an existing 3D Secure process;

FIG. 7 is a flow chart showing a new authentication process inaccordance with the present invention;

FIG. 8 is a flow chart showing a new authentication process inaccordance with the present invention;

FIG. 9 a is a flow chart showing the process of authenticating thewallet application using a SecureCode process;

FIG. 9 b is a flow chart showing an authenticated wallet applicationbeing used for subsequent purchases; and

FIG. 10 is a flow chart showing an authentication system wherein thefeatures of the MPI and the ACS has been incorporated into the walletserver.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to FIG. 1, the present invention is centered around amobile phone 10 associated with a payment card, e.g., a credit card,debit card or prepaid card. The mobile phone is preferably capable ofstoring and/or running a wallet application 12, which is preferably abrowser-based mobile application capable of storing selected informationsuch as a cardholder name, card alias, billing/shipping address, etc.,locally on the phone or in a cloud server. In one preferred embodiment,the mobile phone is a “smart phone”, and the wallet application isstored in a memory device located in the phone. It is contemplatedherein that the system and method of the present invention will enablepayments across multiple channels of commerce, e.g., a POS payment 14by, for example, a PayPass terminal, a remote mobile payment 16initiated by a mobile phone, and/or a web-based payment 18.

As further described in FIG. 1, the present invention contemplates theuse of various authentication tools including an offline PIN 20, aSecureCode PIN 22, and/or an online PIN 24. It will be recognized thatthe foregoing mentioned PINs are currently in use in the marketplaceand, accordingly, the use of such already existing PINs can facilitatethe implementation of the present system. Of course, it is contemplatedherein that a new independent PIN (apart from the mentioned PINs) can becreated specifically for use with the present invention.

Offline PIN 20 preferably utilizes an offline PIN verification processwhereby the PIN entered by the consumer is verified by a secure elementlocated on phone 10. In this process, the wallet plays the role of a“virtual terminal”, interacting with the secure element, and uponverification of the PIN, passes the CHIP token (ARQC) to the merchantfor authorization. In this “virtual terminal”, the secure element servesthe role as the “card”. Offline PIN 20 can, for example, be used inconnection with a PayPass payment.

Secure Code PIN 22 is a PIN associated with a card enrolled in theMasterCard SecureCode system. It is contemplated herein that theSecureCode system could also utilize a password and/or code, rather thana PIN.

Online PIN 24 is used in an online PIN verification process whereby thewallet application 12 plays the role of a “virtual terminal”,interacting to encrypt the PIN for transmission to the merchant. The useof an online PIN verification process may provide greater flexibility inauthenticating transactions by, for example, allowing an issuing bank toauthenticate the transactions associated with its cardholders withoutthe need for the issuing bank to enroll/register its cardholders and/oradopt new infrastructure.

Users may have different instances of wallet application 12 on differentphones. A sync service can maintain the various instances synchronizedwith an online server (similar to how browser bookmarks can be storedoffline in different instances of an internet browser and besynchronized between various machines.) Merchants can add a piece ofcode to their checkout button that invokes the wallet application.During checkout, users select card and shipping address (if needed). Theauthentication PIN is entered into the phone in response to a promptfrom the mobile application. The wallet passes back the information tothe merchant who submits this information through existing channels(internet gateway or payment processor), i.e., no changes are requiredto existing processes or integration.

In one preferred embodiment, the wallet application may be a browserHTML 5 application (not a native application) that self-installs in themobile phone or computer browser on the first use.

In another preferred embodiment, the wallet application can securelystore information on the phone (shipping address, card alias, securetoken, etc.). This information can be used to authenticate to the remoteserver. This also enables offline transactions. The mobile applicationcan preferably “talk” to the secure element on the phone. In thisregard, the mobile application could play the role of a virtual POSterminal in initiating card present CHIP plus PIN transactions.

In accordance with the present invention, a consumer may use his phoneor computer to shop at a web-based retailer. When the consumer is readyto check out, he will preferably have the option of clicking a checkoutbutton associated with the present system. Clicking the button promptsthe consumer to provide his username and password to log-in, and toconfirm both the payment card to be used and the shipping address towhich the item is to be sent. Thereafter, the system will prompt theconsumer to enter the authenticating PIN, and the transaction is thencompleted. At that point, the consumer is preferably returned to themerchant's site.

The present invention provides several benefits to the consumer. Moreparticularly, the present invention provides easy and convenientcheckout through a form fill or pass through function, which ispreferably part of the wallet application. The present invention offerssecure payments via a PIN, or other biometric parameters such as a voiceprint or fingerprint. In this regard, the smart phone may be providedwith a biometric reader and/or analyzer.

The present invention also provides benefits to the merchant including apotential liability shift from the merchant to the authorizing bank forall wallet-based transactions. More particularly, the use of anauthentication process for remote transactions reduce the risk of fraudassociated with such transactions, and may limit/reverse the shifting offraud liability from the authorizing bank to the merchant. The use ofthe authentication process described herein may also provide moreattractive economics to the merchant through access to lower feestructures, depending on the consumer authentication method. The presentinvention also provides limited integration impact in that it provides asimple wallet API to pass card details, shipping information andsecurity tokens, and does not require any new contractual relationships(i.e., it leverages existing card acceptance). Finally, the presentinvention is backwards compatible, (i.e., it provides native support forSecureCode) thus resulting in better consumer experience/ergonomics.

The wallet application of the present invention provides a comprehensivesolution to financial transactions conducted across multiple channels ofcommerce. The present wallet application provides a simple and winningproposition to consumers, and provides a form fill option in aninnovative application. The present invention can use existing paymentnetworks (e.g., Mastercard worldwide system) which are already acceptedby merchants, thereby eliminating the need for heavy integration, whileproviding more security and better economics. The present invention doesnot require issuing banks to implement new requirements since the systemcan function with existing authorization techniques, e.g., SecureCode,CHIP and PIN and/or online PIN. The present invention also contemplatesthe long term convergence path of the three commerce platforms—retail,e-commerce and mobile—towards a mobile phone centric system. The presentinvention also provides the potential to deliver incremental top linerevenue growth by 1) protection of transaction volumes and revenues; 2)by providing an innovative and proprietary approach with the option toprice different services to issuers, merchants or partners (e.g.,directory service, wallet service, etc.); and 3) by providingflexibility for later expansion (new funding source, secure elements,etc.).

It is also contemplated that the authentication processes describedherein can be used in applications where the consumer owns a “dumbphone”. For example, in applications where the consumer is conducting ane-commerce transaction through his computer, or has initiated a call toa call center, and the consumer does not own a smart phone, the presentsystem can utilize existing SMS messaging or other messaging technologyto contact the “dumb phone” of the consumer and request the entry of aPIN. Upon receipt of the PIN from the “dumb phone”, the transaction canbe authenticated and completed.

FIG. 2 is a flow chart depicting the wallet application of the presentinvention being used in an e-commerce transaction (e.g., acomputer-initiated transaction) with a secure element and an offlinePIN. In step 100, the consumer selects the “wallet” icon on themerchant's site. The wallet application is then opened at step 102 bythe browser on the user's computer. The consumer then logs into thewallet application (step 104). The appropriate payment card and shippingdetails are selected (step 106), and the card's PAN is then sent to thewallet server (step 108). In step 110, the wallet server requests theCard Verification Method (CVM) from the MasterCard directory. Thisdirectory may be based on an expanded version of the currently existingSecureCode directory, or may be an entirely new directory. Theappropriate CVM is confirmed at step 112. The wallet server theninitiates the CVM check (step 114). A message to enter the PIN is thendisplayed on the browser (step 116) and on the mobile phone (step 118).The consumer then enters the offline PIN into the mobile phone in step120. In step 122, the offline PIN is verified by the secure element onthe phone. An “OK” message is displayed on the phone (step 124), and theARQC is transmitted to the wallet server (step 126). The browser isrefreshed (step 128), the authentication result is transmitted to theMasterCard directory (step 130), and the authorization data istransmitted to the browser (step 132). The transaction is thenauthorized by the merchant at step 134, and the approval is displayed atstep 136, resulting in a happy consumer (step 138).

FIG. 3 is a flow chart depicting the wallet application of the presentinvention being used in an e-commerce transaction (e.g., acomputer-initiated transaction) with a SecureCode PIN. In step 200, theconsumer selects the “wallet” icon on the merchant's site. The walletapplication is then opened at step 202 by the browser on the user'scomputer. The consumer then logs into the wallet application (step 204).The appropriate payment card and shipping details are selected (step206), and the card's PAN is then sent to the wallet server (step 208).In step 210, the wallet server requests the Card Verification Method(CVM) from the MasterCard directory. This directory may be based on anexpanded version of the currently existing SecureCode directory, or maybe an entirely new directory. The appropriate CVM is confirmed at step212. The wallet server then initiates the SecureCode authenticationprocess (step 214). A “check phone” message is then displayed on thebrowser of the computer (step 216) and a message to enter the SecureCodePIN is displayed on the mobile phone (step 218). The consumer thenenters the SecureCode PIN into the mobile phone in step 220. In step222, the wallet server packages the SecureCode for validation. TheSecureCode is then verified at step 224. This verification process willbe discussed in greater detail hereinbelow. Once verified, an AAV issent to the wallet server (step 226). An “OK” message is displayed onthe browser (step 228) and on the phone (step 230). The authenticationresult is transmitted to the MasterCard directory (step 232), and theauthorization data (step 234) is transmitted to the merchant forauthorization (step 236). The transaction is then authorized at step238, and the approval is displayed at step 240, resulting in a happyconsumer (step 242).

FIG. 4 is a flow chart depicting the wallet application of the presentinvention being used in an e-commerce transaction (e.g., aphone-initiated transaction) with an online PIN. In step 300, theconsumer selects the “wallet” icon on the merchant's site. The consumerthen selects the wallet application (step 302), which then displays alog in form (step 304). Alternatively, the wallet may be auto-detected.The consumer logs in at step 306, views the listed cards at step 308,and thereafter selects the appropriate payment card and shipping details(step 310). At step 312, the wallet questions whether an online PIN isassociated with the card. The existence of the online PIN is confirmedat step 314. In step 316, the wallet requests entry of the online PINinto the phone. The online PIN is entered at step 318. Thereafter, theonline PIN is encrypted (step 320), and forwarded to the merchant forauthorization (step 322). The transaction is validated at step 324,payment is approved at step 326, resulting in a happy consumer (step328).

FIG. 5 is a flow chart depicting the wallet application of the presentinvention being used in an e-commerce transaction (e.g., aphone-initiated transaction) without a secure element on the phone,without a SecureCode, and without an online PIN. In step 400, theconsumer selects the “wallet” icon on the merchant's site. The consumerthen selects the wallet application (step 402), which then displays alog in form (step 404). Alternatively, the wallet may be auto-detected.The consumer logs in at step 406, views the listed cards at step 408,and thereafter selects the appropriate payment card and shipping details(step 410). At step 412, the wallet questions whether a SecureCode isassociated with the card. The card is determined not to be in theSecureCode directory at step 414. The authorization data is then passedto the wallet at step 416, which sends such data to the merchant forauthorization (step 418). The transaction is validated at step 420,payment is approved at step 422, resulting in a happy consumer (step424). In this type of scenario, the issuing bank can accept or declinethe transaction in accordance with its existing standards. For example,the issuing bank may establish protocols whereby certain e-commerceand/or remote transactions are not approved in the absence of asuccessful authentication process.

An existing 3D Secure process is shown in the flow chart of FIG. 6. Moreparticularly, the existing 3D Secure process includes step 501 wherein amerchant initiates an authentication request, and pings the merchantplug-in (MPI) with the cardholder financial instrument information. Itshould be understood that the cardholder has already accessed themerchant's webpage, and has indicated his desire to purchase aparticular product using a particular payment card. In step 502, the MPIidentifies the appropriate card type, and sends an authenticationrequest (VEReq) to the relevant directory server. In step 503, thedirectory server identifies the appropriate access control server (ACS),and requests an authentication response. In step 504, the ACS identifiesthe card and cardholder, and sends a response (VERes) withauthentication prompts within the ACS URL. In step 505, the directoryserver forwards the authentication response (with the ACS URL) to theMPI. In step 506, the MPI sends the payment authentication request(PAReq) to the merchant for display during checkout. The paymentauthentication request includes the ACS URL. In step 507, the paymentauthentication request is sent from the merchant to the ACS—in otherwords, the merchant calls the ACS URL. In step 508, the ACS sends apop-up window to the merchant which appears on the cardholder's browserrequesting the cardholder to enter authentication credential. In step509, the cardholder enters the requested authentication credentials, andsuch information is sent back to the ACS for authentication. In step510, the ACS validates the authentication credentials, and if correct,sends an AAV confirming authentication to the merchant. Thereafter, themerchant proceeds to authorize the transaction in customary fashion.

One drawback to the process described above with respect to FIG. 6 isthat the authentication process requires the use of a pop-up windowappearing during the online transaction process. Many online shoppershave been taught to be suspicious of pop-up windows, and are reluctantto enter relevant financial information in such a window for fear thatthe pop-up window could be coming from a fraudulent website and/or be apart of a phishing scam.

The new embodiments of the present invention shown in FIGS. 7 and 8 notonly address the drawbacks of relying upon pop-up windows duringauthentication, but provide the merchant with better control over thecheckout experience presented to its customers. These new processes areshown in the context of a phone with a wallet application. However, itis to be understood herein that these processes can also be used inconventional cardholder browser/merchant transactions, i.e., atransaction performed without a phone and/or wallet application.

Turning first to FIG. 7, the wallet detects the checkout page and makesa payment request (step 601). The wallet then authenticates the user, atwhich point the user can select the payment type (step 602). The walletserver then determines which branded 3DS Directory to use based on theaccount number selected (step 603). The user's participation is thenverified (step 604). Next, the wallet retrieves the SecureCode (step605). In particular, the user is prompted to enter his/her SecureCode aspart of the wallet sign-in or as a separate prompt (step 605 a), and/orthe wallet retrieves/generates the user's SecureCode which has beensecurely stored on the phone and wallet server (step 605 b). TheSecureCode is then sent to the bank for verification (step 606). Next,the wallet form fills the payment details, including the AAV, in themerchant page (step 607). The merchant then authorizes the transactionin normal fashion (step 608), and receives the necessary approval (step609).

Turning now to FIG. 8, the process includes a step 701 wherein themerchant initiates a transaction request. It should be understood thatthe merchant has already integrated his existing payment system with thewallet application such that the merchant can receive authenticationinformation from the wallet. In step 702, the wallet initiates anauthentication request, and pings the MasterCard Merchant Plug-In(MC-MPI) formed in accordance with the present invention with thecardholder financial instrument information. In step 703, the MC-MPIidentifies the appropriate card type, and sends a verify enrollmentrequest (VEReq) to the relevant directory server. In step 704, thedirectory server identifies the appropriate ACS, and forwards the verifyenrollment request (VEReq), expecting a verify enrollment (VERes)response. In step 705, the ACS identifies the card and cardholder, andsends a response (VERes) with the ACS URL. In step 706, the directoryserver forwards the response (VERes with the ACS URL) to the MC-MPI. Atthis point, rather than MC-MPI communicating back to the walletapplication, the MC-MPI communicates directly with the ACS. Moreparticularly, in step 707, the MC-MPI sends a payer authenticationrequest (PAReq) to the ACS. In other words, the MC-MPI formats theexpected request and calls the ACS URL. In step 708, the ACS respondswith the traditional browser HTML markup to the MC-MPI. In step 709, theMC-MPI then interprets the HTML markup, including the authenticatingcriteria, and extracts the needed elements from the HTML markup andtranslates into the API protocol which is then communicated to thewallet. The wallet then displays an authentication request to thecardholder, requesting that the cardholder enter their authenticationcredentials. In step 710, the wallet communicates the cardholderauthentication credentials to the MC-MPI via API protocol. In step 711,the MC-MPI translates the cardholder authentication credentials into theformat expected by the ACS and uses an HTTP POST to communicate thecredentials to the ACS. In step 712, the ACS validates theauthentication credentials, and sends a payer authentication response(PARes including AAV) back to the MC-MPI representing the authenticationresult. In step 713, the MC-MPI passes the AAV and information receivedfrom the ACS to the wallet via API protocol. In step 714, the walletpasses the AAV and authentication message to the merchant via APIprotocol. The merchant then proceeds to authorize the transaction incustomary fashion.

As described, in step 708 of FIG. 8, the ACS sends the authenticationcriteria to the MC-MPI for translation. In other words, rather thansending a the HTML markup served by the ACS directly back to the walletapplication, the necessary information for authentication is sent to theMC-MPI via the HTML markup, which then can translate that informationand forward it in a predetermined manner. More particularly, withrespect to a wallet application, such application could be designed tocommunicate with the MC-MPI in a consistent and known manner whereby aconsumer does not receive a “suspicious” pop-up window. Rather, thewallet application can cooperate with the MC-MPI such that everyauthentication transaction is conducted in a recognized window.

As mentioned hereinabove, the processes described in FIGS. 7 and 8 arealso applicable to non-wallet based transactions. More particularly, forbrowser-based transactions utilizing a 3D Secure process, or othersimilar process, the forwarding of a pop-up window from the ACS directlyback to the merchant can introduce uncertainty into the authenticationprocess. Accordingly, the MC-MPI shown in FIG. 8 could, in anotherapplication, communicate directly with a cardholder browser/merchant inthe absence of a phone. Such an arrangement could allow the merchant tocontrol how the authentication request appears to the customer duringthe checkout process. In other words, by sending the authenticationcriteria through the MC-MPI (where it is translated), the translatinginformation can be sent back to the merchant's webpage in apredetermined and selected manner, thus giving the merchant greatercontrol over the shopping experience of its customers—while alsoeliminating the usage of pop-up windows.

In another embodiment, the wallet is used as a security supplement. Inone application, this is accomplished by authenticating the walletitself. More particularly, the wallet application is loaded onto thephone, and a payment card is entered into the application. The user'sidentity is verified, and the wallet thereafter holds the payment datain a secure manner. When the user subsequently uses the wallet to make apurchase, the wallet can communicate to the merchant that the walletitself has been authenticated, thus decreasing the likelihood of afraudulent transaction. Referring to FIG. 9A, the SecureCode process canbe used to authenticate a wallet. In this regard, the user signs intothe wallet and registers a card (step 800). The SecureCode process isinitiated for authentication (step 801). The 3DS directory is thenaccessed at step 802. Next, the user is prompted for the SecureCode(step 803). The SecureCode is verified by the ACS (step 804). Ifauthenticated, the payment card is accepted and stored in the wallet ina secure manner (step 805). Of course, it is contemplated herein thatother process could be used to authenticate the wallet, such as anonline PIN or a unique wallet PIN/code provided by the issuing bank.

During a future transaction, the wallet can communicate to the merchantthat the card has previously been authenticated, thus reducing thelikelihood of a fraudulent transaction. Turning now to FIG. 9B, theprocess shown is similar to that shown in FIG. 7 with the exception ofstep 810. After the user signs into the wallet, the wallet can determinewhether to seek additional authentication from the user. For example,for certain transactions (e.g., a transaction exceeding a particularmonetary value, a transaction outside of the user's normal spendinghabits, etc.) the issuing bank can require authentication beyond thewallet authentication. Thus, if additional authentication is required,the wallet will initiate the SecureCode process. If additionalauthentication is not required, the wallet will bypass the SecureCodeprocess and proceed with the transaction. Of course, it is contemplatedherein that the subsequent authentication process can be other than theSecureCode process, e.g., an online PIN.

In another preferred embodiment, a wallet MPI is contemplated whereinthe wallet becomes the new SecureCode MPI for merchants. Referring toFIG. 10, the wallet detects checkout at the merchant at step 901. Thewallet then authenticates the user (step 902), and payment details areselected (step 902). The wallet server then determines that the bank isthe wallet ACS customer, and that no further authentication is necessary(step 803). The remainder of the process is the same as shown in FIG. 7.It is to be noted that the process shown in FIG. 10 does not require theMPI and the ACS shown and described in FIG. 7. Thus, this embodiment mayprovide a simple way for merchants to deploy the SecureCode processwithout the need for investment in infrastructure by both the merchantand the issuing bank.

It will be appreciated that the present invention has been describedherein with reference to certain preferred or exemplary embodiments. Thepreferred or exemplary embodiments described herein may be modified,changed, added to or deviated from without departing from the intent,spirit and scope of the present invention, and it is intended that allsuch additions, modifications, amendments and/or deviations be includedin the scope of the present invention.

1. A method for removing pop-up windows during an authentication processinvolving a cardholder using a payment card in an electronictransaction, comprising the steps of: sending authentication criteriadirectly from an access control sever to a merchant plug-in; translatingsaid authentication criteria to a language compatible with said merchantplug-in; forwarding said authentication criteria through said merchantplug-in to a device operated by said cardholder for entry of saidauthentication credentials associated with said payment card in theabsence of a pop up window.
 2. The method according to claim 1, whereinsaid authentication criteria are transmitted in HTML markup, and furthercomprising the step of translating said HTML markup into applicationprogramming interface protocol.
 3. The method according to claim 2,further comprising the step of returning said authentication credentialsthrough said merchant plug-in to said access control server forvalidation of said credentials.
 4. The method according to claim 3,further comprising the step of translating the authenticationcredentials received by said merchant plug-in from said applicationprogramming interface protocol to said HTML markup.
 5. The methodaccording to claim 4, further comprising the step of sending avalidation response from said access control server to said merchantplug-in for subsequent transmission to a merchant participating in saidelectronic transaction.
 6. A method of authenticating the identity of acardholder during an electronic transaction involving a payment cardutilizing 3D Secure protocols, comprising the steps of: a) sending averify enrollment request to a directory server; b) identifying anaccess control server associated with said card; c) sending a verifyenrollment response from said access control server to said directoryserver, said verify enrollment response including a URL address of saidaccess control server; d) sending said verify enrollment response to amerchant plug-in associated with a merchant involved in said electronictransaction; e) sending a payor authentication request from saidmerchant plug-in to said access control server; f) sending a browserHTML markup from said access control server to said merchant plug-in; g)extracting data from said HTML markup associated with saidauthentication of said card; h) transmitting said extracted data to awallet application associated with said cardholder for entry ofauthentication credentials; i) sending said credentials from said walletapplication through said merchant plug-in to said access control server;j) sending said translated credentials from said merchant plug-in tosaid access control server for validation; k) transmitting, uponvalidation of said credentials, a payer authentication response and apayment authorization from said access control server to said merchantplug-in; l) transmitting said authorization from said merchant plug-into said wallet application for subsequent transmission to said merchant.7. The method according to claim 6, wherein said extracting stepincludes the further steps of interpreting said HTML markup.
 8. Themethod according to claim 6, comprising the further step of translatingsaid extracted data into application programming interface protocol. 9.The method according to claim 6, wherein said authentication credentialsare sent from said wallet application to said merchant plug-in viaapplication programming interface protocol.
 10. The method according toclaim 6, further comprising the step of displaying a request for saidcardholder to enter authentication credentials into said cardholder'sphone.
 11. The method according to claim 6, further comprising the stepof translating said credentials received from said wallet applicationinto an appropriate format for receipt by said access control server.12. The method according to claim 11, further comprising the step oftranslating said credentials from said application programming interfaceprotocol to said HTML markup
 13. A method of reducing fraudulenttransactions associated with electronic commerce, comprising the stepsof: providing a wallet application for storage on a mobile phone;entering of data associated with a payment card into said walletapplication; authenticating the identity of the cardholder associatedwith said payment card via an authentication process; placing saidwallet application into an authenticated state whereby the dataassociated with said payment card is stored in a secure manner withinsaid wallet application; and communicating said authenticated state ofsaid wallet to a merchant during said electronic translation.
 14. Themethod according to claim 13, comprising the further steps of: analyzingsaid financial transaction to assign a risk factor to such transaction;determining whether further authentication is required based upon saidassigned risk factor.
 15. A system for authenticating the identity of acardholder during an electronic transaction involving a payment cardenrolled in an authentication program, comprising: a directory serverfor verification of the enrollment of said card in said program; anaccess control server in communication with said directory server, saidaccess control server containing authentication credentials associatedwith said card; a merchant plug-in in communication with said directoryserver and said access control server; and wherein said merchant plug-inis capable of receiving authentication criteria directly from saidaccess control server and is further capable of translating saidcriteria to a language which allows transmission of said criteriathrough said merchant plug-in to an electronic device associated withsaid cardholder.
 16. The system according to claim 15, wherein saidmerchant plug-in includes a translator for extracting data from saidauthentication criteria received from said access control server. 17.The system according to claim 15, further comprising a mobile phone anda wallet application, said application being stored on said phone andadapted to receive said authentication criteria from said merchantplug-in for subsequent entry of said validation credentials.